SPACE 1/SPACE - Library 1 - Volume 1.iso/utilitys/93/ppaccell/pcpaccel.txt

Text File | 1987-10-12 | 6.1 KB | 199 lines

    ACCELLERATING XMODEM TRANSFERS USING TIMED DELAYS

         by Thomas Zerucha / 24075 Lee Baker / Southfield, MI 48075

    The problem:
         Telenet will not send a packet unless one of two things occurs:
         1. 128 characters fill a complete packet
         2. A programmable timeout occurs, normally 1/10th of a second
            (this is set as 1/20th of a second multiplied by parameter
              4, as in @SET 4:2<cr> is .1 sec, 4:3 is .15, 4:4 is .2 etc.).

         When transmitting Xmodem packets, the data will collect at your
         end until 128 characters have been sent, and then be sent over the
         network, and be sent (starting from the first character) out at the
         far end.  Note that the first character goes out at the far end
         AFTER the 128th character is sent (and usually later, since Telenet
         is not instantaneous).  This 128 character delay is over 1 sec at
         1200 baud, and 4-1/4 seconds at 300 baud.

         Fortunately, there is a way to speed things up a little by taking
         advantage of the second transmit condition.

         WARNING: this method increases the number of packets sent.  Under
         non-flat-rate conditions you are more likely to exceed your kilo-
         packet limit and that may prove costly.  This is intended for
         normal (evening and weekend) PC Pursuit hours.

    A Partial Solution:

         What would happen if we added a .1 second delay in the middle of
         the block?  The packet would be sent half sooner.  So if we can
         set up delays so that data would always be at the far end, and
         the first packet would be sent as soon as possible, we would speed
         up Xmodem transferrs quite a bit.  We have to be careful about
         packing, as the following diagram shows:

         Transmitter:
         TTTTTTTTTTTT---TTTTTTTTTTTT---.................*TTTTTTT->
         Receiver:
                   RRRRRRRRRRRR---RRRRRRRRRRRR*---

         * ack     '---' timeout delay

         Note that there is a delay in the receiver, not good if we want
         peak performance.  The best way to fix this is to use shrinking
         packets, the last packet being between 1 and 2 times the delay
         time in length, i.e. a number of characters that would take
         between .1 and .2 seconds to send, and then lengthening each
         packet until the full XModem packet length is contained.  This
         impacts the number of characters in the first packet - in the
         last packet, it can be 4-7 characters and qualify.  But 4+8+...
         adds to either 112 or 144.  Making the first packet too short
         wouldn't speed things up as much as making everything perfect.








                                                    Accellerating Xmodem Page 2


         so we have to add characters to each packet:

              112 =  28  24  20  16  12   8   4
              +3 on each
              133 =  31  27  23  19  15  11   7

         note that they still decrease by exactly 4.  If checksum is used
         and 132 characters (which don't add exactly), any subpacket or group
         of successive subpackets can be shortened by one, i.e for 130 chars

              130 =  30  26  22  19  15  11   7

         This will cause the following:

         TTTTTTTTTTTT---ttttttttt---TTTTTT---ttt---........*
                   RRRRRRRRRRRRrrrrrrrrrRRRRRRrrr*---

         Values which work for 1200 Baud (the above is for 300) are

              133 = 52 39 27 15

         This works because each group fits within it's previous subpacket.

         Whatever delays inherent in the network will remain, however, there
         will be a savings of .63 sec/Xmodem block @ 1200 Baud, and 2.2 sec
         at 300 Baud.  This will not apply if Telenet is constantly changing
         it's load, but this is rare in the off hours.  Graphically:

         TTTTTTTTTTTT---ttttttttt---TTTTTT---ttt---........*
                     ppp        pppppp   p
                     RRRRRRRRRRRR...rrrrrrrrrRRRRRRrrr*---

         p is the time it takes Telenet to send a packet

         But with a constant delay using accelleration:

         TTTTTTTTTTTT---ttttttttt---TTTTTT---ttt---.............*
                     ppp        ppp      ppp   ppp         ppp
                     RRRRRRRRRRRRrrrrrrrrrRRRRRRrrr*---

         The normal way:

         TTTTTTTTTTTTtttttttttTTTTTTttt---....................................*

                             ppp ppp                      ppp
                             RRRRRRRRRRRRrrrrrrrrrRRRRRRrrr*---

    Notes:

         This technique is effective at accelerating any subpacket that can
         be broken so that the largest packet is less than 128 characters
         (minus .1 sec worth of characters - 116 for 1200 baud, or 124 for
         300 baud).  So this will not help Ymodem (1k) packets, but will help
         256 byte packets.  Also remember to add characters up to the maximum
         length of .2 seconds, with many splits this can be significant.








                                                    Accellerating Xmodem Page 3


         (3 chars/block at 300 baud, 11 c/blk at 1200).  At 1200 Baud:

              133 = 52 39 27 15     <= optimal
                     5  5  5 -15
              133 = 57 44 32

         Note that both of these hold the property we are looking for, but
         the first is 5 characters (.4 sec) longer for the first packet.
         If the first number would be greater than 128, then the method
         would not help significantly (since the delay would be 0 for the
         129th character, but .1 sec otherwise).

         If we try to divide finer, we end up with packets smaller than the
         delay, or bigger than the previous packet + delay:
              133 = 48 36 24 12 13
                     1  1  1  1 -4
              133 = 49 37 25 13  9
                     3  2  2  2 -9
              133 = 52 39 27 15     <= optimal